1장. 미래는 도래했다

출처 — 진 킴·스티브 예기, 『바이브 코딩 프로덕션의 원칙』(제이펍), 1장 (pp. 63~78). 원문 PDF vibe_coding_final_v11_260913.pdf (2026-09-13 판)

안드레이 카르파티가 2025년 2월에 이름 붙인 '바이브 코딩'이 SF적 상상에서 현실의 개발 관행으로 굳어지는 과정과, 그 변화가 개발자를 '라인 담당자'에서 '헤드 셰프'로 밀어 올린다는 이 책 전체의 핵심 주장을 소개한다.

학습 목표

이 장을 끝내면 다음을 할 수 있다.

• 바이브 코딩의 정의와 등장 배경(안드레이 카르파티의 2025년 발언)을 설명한다
• 바이브 코딩을 둘러싼 신중론과 급진론의 입장, 그리고 두 진영의 공통 합의점을 구분한다
• 아마추어 바이브 코딩과 성숙한 바이브 코딩의 차이를 원문의 사례로 비교한다
• 저자의 생산성 사례를 근거로 '헤드 셰프' 비유가 뜻하는 책임의 전환을 설명한다
• FAAFO 다섯 요소를 나열하고 각각이 가리키는 가치를 구분한다

전체 흐름도

1장. 미래는 도래했다
   │
   ├─▶ §1 SF가 그린 미래, 지금의 현실
   │      LLM·AI 코딩 에이전트의 등장 — "말하면 작동하는 소프트웨어"
   │
   ├─▶ §2 바이브 코딩의 등장
   │      카르파티의 2025-02 정의 → X 확산 → 업계 증언(개리 탄·보리스 체르니·토비 뤼트케)
   │
   ├─▶ §3 바이브 코딩을 둘러싼 논쟁
   │      신중론(브렌던 험프리스·제시 영) ↔ 급진론(세르게이 브린)
   │      └─▶ 공통 질문: "어디까지 뇌를 꺼놓아도 되는가?"
   │
   ├─▶ §4 어른을 위한 바이브 코딩
   │      아마추어 바이브 코딩 ──╮
   │                           ├─▶ 성숙한 바이브 코딩(엔지니어링 원칙 유지 + 속도)
   │      B2C 인증 기능 사례 ───╯       레거시 코드: 분석→회귀 테스트→수정
   │
   ├─▶ §5 생산성 10배 향상 사례 — 진의 이야기
   │      "원고 대신 도구를 만든다"는 판단 → 4일·4,176줄 → 과거 대비 최대 16배
   │
   ├─▶ §6 당신은 라인 담당자가 아닌 헤드 셰프다
   │      구현 위임 ≠ 책임 위임 — 결과는 전적으로 당신 몫
   │
   └─▶ §7 헤드 셰프로서의 더 넓은 책임 (+ 결론)
          한 사람 → 팀 규모 책임(병렬 작업·통합·표준·온보딩·조율)
          └─▶ FAAFO: fast·ambitious·autonomous·fun·optionality

0. 용어 사전

참고 — 이 장은 책의 첫 장이라, 선행 용어를 앞 장이 아니라 일반적인 AI/개발 상식에서 가져온다(2장부터는 바로 앞 장을 선행으로 표시한다). 위쪽 4개가 그 선행 용어다. 낯설면 아래 정의부터 읽는다.

1. SF가 그린 미래, 지금의 현실

1960년대 이후 상영된 〈스타트렉〉 같은 SF 작품은 사람과 컴퓨터가 자연스럽게 대화하는 미래를 그려 왔다. 인간이 말을 걸면 컴퓨터가 그 뜻을 이해하고 원하는 일을 수행하는 세계다. 저자들은 불과 얼마 전까지도 이런 장면을 직접 마주하리라고는 상상하지 못했지만, ChatGPT와 AI 코딩 어시스턴트·AI 코딩 에이전트의 등장으로 인간이 컴퓨터와 상호작용하는 방식이 완전히 바뀌었다고 말한다. 개발자에게는 특히 그렇다. 이제 LLM을 통해 컴퓨터와 복잡하고 지적인 논의를 하고, 여러 접근법을 두고 토론하며, 자연어로 복잡한 문제를 함께 풀어내는 시대를 맞이했다는 것이다.

이 관찰은 두 저자의 개인적 배경과 대비되기에 더 무게가 실린다. 스티브 예기는 오랫동안 신기술에 회의적인 '후발 수용자'였고, 진 킴은 소프트웨어 생산성을 높인다고 주장하는 방법론들의 근거를 비판적으로 검증해 온 연구자였다. 그런 두 사람의 생각을 뒤집을 만큼 눈에 띄는 증거가 최근 나타났다는 것이 이 책을 쓴 동기다.

LLM 기반의 대화형·에이전트형 AI 도구를 사용한 프로그래밍은 초자연적으로 보이는 능력을 발휘한다. 원하는 바를 설명하기만 하면 거의 즉시 작동하는 소프트웨어가 만들어지는 세계로 다가가고 있다는 것이 저자들의 진단이다. 무언가 잘못됐을 때 몇 시간을 디버깅하는 대신, 바꿔야 할 점을 말로 설명하면 해결되고, 때로는 AI가 스스로 문제를 찾아내 수정하기도 한다.

AI 동료는 머릿속 원대한 비전을 실행 가능한 작업 단위로 세분화하도록 돕는다. 그중 일부는 에이전트가 스스로 처리하도록 위임하고, 일부는 직접 AI와 협업해 설계·구현을 진행할 수 있다. AI는 허락하는 한 실무 담당 개발자·멘토·디자이너·아키텍트·코드 리뷰어·페어 프로그래머로서 모든 단계에서 도움을 줄 수 있다. AI 파트너와 함께 작업하면 아이디어가 번개처럼 빠르게 뇌에서 컴퓨터로 전달되어 실행 가능한 코드로 바뀌는 느낌을 받는다 — 이 협업의 결과는 가장 뛰어난 아이디어 하나만이 아니라, 머릿속에 있던 수많은 아이디어까지 실제로 구현할 수 있게 만든다는 데 있다. AI는 단순히 코드를 생성하는 데 그치지 않고, 아이디어 브레인스토밍·선택지 평가·프로젝트와 팀 관리·전략 수립에까지 동참하는 대화 파트너가 됐다.

2. 바이브 코딩의 등장

'바이브 코딩'이라는 말을 처음 쓴 사람은 안드레이 카르파티다. 그는 OpenAI에서 ChatGPT 개발에 참여했고 테슬라에서 AI 디렉터로 자율주행용 컴퓨터 비전 시스템을 이끌었던, 오늘날 가장 영향력 있는 AI 연구자 중 한 명이다. 2025년 2월, 그는 "완전히 감(vibe)에 몸을 맡기고, 기하급수적 변화를 받아들이며, 코드 존재 자체를 잊는 새로운 형태의 코딩이 등장했다. 나는 이 방식을 '바이브 코딩'이라 명명한다"라는 글을 남겼다.

카르파티는 이렇게 덧붙였다 — "나는 그냥 말만 한다. 키보드엔 거의 손도 안 댄다. '사이드바의 패딩을 절반으로 줄여줘'처럼 정말 단순한 작업도 귀찮아서 코드를 보지 않고 작업한다. 항상 '모두 승인'을 누르고, 코드 변경분을 읽지도 않는다. 에러가 나면 그냥 에러 메시지를 복사해 붙인다. 이 작업만으로도 보통은 에러가 해결된다." 다만 그의 고백에서 가장 눈여겨볼 대목은 "코드가 내 이해 범위를 넘어설 정도로 커지면, 한동안은 진지하게 코드를 읽긴 해야 한다"는 부분이다 — 카르파티 스스로도 '코드 이해'보다 '결과'를 우선시하는 이 워크플로가 무한정 통하지는 않는다고 인정한 것이다.

이 발언은 X에서 폭발적인 반응을 얻으며 기술 업계 전반으로 퍼졌고, 몇 달 만에 개발 현장의 일상적 관행이 됐다. Y Combinator CEO 개리 탄은 "2025년 겨울 배치(당시 함께 선발된 스타트업 그룹) 25%가 전체 코드의 95%를 LLM으로 생성하고 있다 … 바이브 코딩의 시대는 이미 도래했다"고 밝혔다. 앤트로픽의 기술 스태프이자 클로드 코드의 기술 리더인 보리스 체르니는 "코딩 에이전트를 쓰면 생산성이 2배 높아진다"고 주장했으며, 일부 개발자는 10배라고까지 평가했다. 이런 추세는 AI 연구소나 스타트업에만 국한되지 않는다 — 2024년 매출 88억 달러, 개발자 4,000명 이상을 둔 캐나다 2위 상장기업 쇼피파이의 CEO 토비 뤼트케는 "인력과 리소스를 더 요청하기 전에, 해당 팀은 AI를 활용해서 원하는 결과를 달성할 수 없는 이유를 먼저 입증해야 한다"고 밝힌 것으로 알려졌다. 저자들은 여기서 중요한 질문을 던진다 — 바이브 코딩을 도입한 기업들은 장기적으로 문제를 자초하고 있는 것은 아닐까?

3. 바이브 코딩을 둘러싼 논쟁

이 질문에 대한 답은 크게 두 진영으로 갈린다. 캔바 CTO 브렌던 험프리스는 "바이브 코딩만으로 프로덕션 수준까지 갈 수 없다"고 말한다. 그는 바이브 코딩을 '엔지니어가 최소한의 검토만 하고 AI에 코드 생성을 맡기는 행위'로 정의하며, 이런 접근은 신뢰할 수 있고 유지 보수 가능한 소프트웨어를 만드는 것과 양립할 수 없다고 본다. 깃랩 수석 엔지니어 제시 영도 비슷한 입장이다 — "내가 온콜일 땐 바이브 코딩 금지!"라는 그의 말은, 코드를 제대로 이해하지 못한 채 커밋하는 리스크와, 새벽 2시에 그 코드를 디버깅해야 하는 사람(바로 온콜 담당자 자신)의 처지를 동시에 겨냥한다.

반대쪽엔 더 급진적인 입장이 있다. 구글 공동 창립자 세르게이 브린은 구글 엔지니어들이 코드 세부 사항보다 제품 방향성에 집중하도록 공격적으로 AI 도구를 활용하라고 독려한다. "엔지니어의 역할은 '무엇을 만들지 결정하는 프로덕트 엔지니어'로 바뀔 것"이라는 그의 주장은, 소프트웨어 엔지니어의 역할이 '코드를 작성하는 사람'에서 'AI를 지휘하는 사람'으로 근본적으로 전환돼야 한다는 뜻이다. 이 진영은 코드가 잘 작동하지 않을 때 수정하는 대신, 제대로 작동할 때까지 코드를 지우고 다시 만드는 디버깅 방식을 옹호하기도 한다.

관점의 차이는 크지만, 흥미롭게도 몇 가지 핵심 사항에서는 기술 리더들의 의견이 일치한다 — AI 코딩 도구가 소프트웨어 개발을 근본적으로 재편하고 있다는 점, 생산성을 향상시킨다는 점, AI 역량이 급속히 진화하므로 개발 방식도 함께 진화해야 한다는 점이다. 카르파티·험프리스·브린이 던지는 질문은 결국 하나로 수렴한다 — "AI를 이용해 소프트웨어를 만들 때, 우리는 과연 어느 정도 수준까지 '뇌를 꺼놓고' 작업해도 되는가?"

4. 어른을 위한 바이브 코딩

유튜브 인플루언서들이 '프롬프트 한 줄로 비행 시뮬레이터 만들기' 같은 자극적인 콘텐츠로 주목을 끄는 동안, 현장의 엔지니어들은 바이브 코딩을 전문 소프트웨어 엔지니어링의 영역으로 가져오는 데 집중하고 있다. AI에게 반복적이고 지루한 구현 세부 사항을 맡기면서도 체계적인 엔지니어링 원칙과 절차를 지키며 작업하는 것 — 저자들은 이를 '어른을 위한, 성숙한 바이브 코딩'이라 부른다.

성숙한 바이브 코딩은 보안 검토·테스트 커버리지 관리·영향 범위 관리·운영 품질 관리를 그대로 포함한다. AI 코딩 어시스턴트 등장 전에도 하던 업무이지만, 차이는 이제 이 모든 걸 누구도 경험해 본 적 없는 속도로 수행한다는 점이다. 예를 들어 B2C 제품의 인증 기능을 작업한다고 하면, 여전히 보안 관련 코드를 한 줄 한 줄 꼼꼼히 검토하고 포괄적인 테스트 스위트를 구축한다 — 다만 그 모든 과정을 훨씬 빠르게 수행한다는 점이 다를 뿐이다. 아무도 구조를 이해하지 못하는 레거시 시스템을 다뤄야 한다면, 먼저 AI로 코드베이스를 분석·문서화한 다음 기존 코드의 동작을 검증하고 회귀를 방지하는 테스트를 작성하고, 그 후에 코드를 수정하는 순서로 작업할 수 있다.

결국 하는 일은 여전히 오랜 시간 쌓아온 엔지니어링 원칙과 전문성을, 더 높은 강도로 적용하는 것이다. 이제 개발자는 헤드 셰프다 — 표준을 세우고, 엄격하게 검수하며, 모든 결과물이 엔지니어링 원칙과 기준에 부합하는지 확인하는 역할을 맡는다. 주방이 빠르게 움직일수록 실수의 가능성과 규모도 함께 커지기 때문에 이 역할은 더 중요해진다. 마이크로소프트 연구원 조너선 라슨이 LLM과 GraphRAG를 사용해 1993년작 DOOM 소스 코드에 플레이어 점프 기능을 추가한 사례가 이를 잘 보여 준다 — 기존 엔진엔 3차원을 처리하는 내부 모델이 없었고 플레이어가 항상 지면에 붙어 있다고 가정하고 설계돼 있었지만, 물리 시스템·플레이어 상태·입력 처리·레벨 로직을 함께 수정하며 결코 단순하지 않은 레거시 수정을 해냈다. 저자들은 이제 한 줄 한 줄 손으로 코드를 정성껏 작성하는 방식에서 벗어나 새로운 제작 방식을 전면적으로 수용할 때라고 믿으며, "굳이 손으로 코드를 써야 할 이유가 없다면, 이제 아무도 그렇게 해서는 안 된다"고 말한다.

5. 생산성 10배 향상 사례 — 진의 이야기

숙련된 엔지니어(100만 줄이 넘는 프로덕션 코드를 직접 작성한 스티브)만 하루에 수천 줄의 실행 가능한 코드를 써내며 생산성을 10배 높일 수 있는 것일까, 아니면 평범한 개발자도 가능한 것일까? 저자는 자신의 경험으로 이 질문에 답한다.

실무 예제(형태 B — 판단 시나리오) 상황 — 이 책의 원고 마감을 72시간도 채 남기지 않은 시점. 마감 후에는 책 내용을 거의 수정할 수 없다. 저자들은 원고를 큰 덩어리로 나눠 LLM에 넣어 중복 아이디어·섹션의 독창성·실천편 순서·각 장 도입부와 결론의 균형을 점검하고 있었는데, 그중 "모든 장의 도입부를 추출해 서로 비교하는" 작업이 특히 지치는 일이었다 — 여러 사람이 쓴 글을 손으로 일일이 합치고 편집해야 했기 때문이다. 잘못된 접근(원래 하던 방식) — 마감이 코앞이니 원고 작업에만 매달리고, 반복되는 추출·비교 작업은 그대로 손으로 계속한다. 실제 선택 — 원고 대신 '생산성 도구'를 만드는 데 시간을 쓰기로 한다. 2022년에 만들어 둔 마크다운 파서를 열어 클로드 코드에게 "여기 .md 파일을 파싱해서 트리 구조로 만드는 코드가 있었던 것 같아. 그 트리를 기반으로 '모든 장 목록 출력'이나 '특정 장의 모든 섹션과 하위 텍스트 가져오기' 같은 작업을 하고 싶어"라고 요청한다. 52분 후 원하던 기능 대부분이 완성됐고, 이후 4일에 걸쳐 쉬는 시간마다 작업해 52개 파일·클로저 코드 4,176줄(실제 기능 2,331줄·테스트 1,845줄)과 문서·보고서 3,000줄 이상을 만들었다. 왜 — 헤드 셰프의 판단 — 반복 작업을 견디는 대신, 반복 작업 자체를 없애는 도구에 시간을 투자하는 쪽을 선택한 것이다. 이 판단 덕분에 책 원고를 배열 슬라이스 문법(Parts [1..3]·Chapter [1,20]처럼 부·장·절 단위로 즉시 추출)으로 다루는 도구가 생겼고, 도입부·결론부만 따로 추출해 장의 균형을 맞추는 작업도 자동화됐다. 저장소의 커밋 히스토리를 분석한 결과 과거 평균 속도 대비 16배, 역대 최고 생산성을 보인 날보다도 5배 빠른 속도였다 — 하루 종일이 아니라 쉬는 틈틈이 낸 성과다.

원문 표기와의 차이 — 저자가 직접 인용한 원출처(ITRevolution 블로그 「The Last 80 Hours Of Editing the 'Vibe Coding' Book」)를 대조하면(2026-09-14 확인), 이 작업은 프롬프트 261개·커밋 35개로 완료됐다. 이 장의 한국어판 인쇄본 본문은 프롬프트 수를 251개로 적고 있으나, 원출처의 수치는 261개다. 학습자료는 검증 가능한 원출처 수치를 따른다.

작업을 마친 후 스티브가 "4,000줄이 넘는 코드를 쓴 기분이 어땠나요?"라고 묻자, 저자는 "솔직히 줄 수를 세본 적도 없다. 그냥 필요한 기능을 마법처럼 빠른 속도로 만들어가는 느낌이었다. 코드가 마치 물 흐르듯 쏟아졌다"고 답했다. 이 사례에서 중요한 것은 '4,176줄'이라는 숫자 자체가 아니라, 반복적이고 지루한 실행을 AI에 맡기면서도 결과가 실제로 정확히 동작하는지 확인하는 책임은 스스로 졌다는 점이다 — 테스트 스위트가 기존보다 거의 6배 늘어난 것도 그 확인 과정의 일부였다.

6. 당신은 라인 담당자가 아닌 헤드 셰프다

AI 없이 개발하던 시절에는 단순한 대시보드 하나를 만드는 데도 무수한 단계를 거쳐야 했다 — 차트 라이브러리를 고르고, 문서를 몇 시간씩 읽고, 설정 옵션을 실험하고, 데이터를 파싱하고, 잘못된 데이터를 걸러내는 함수를 작성하고, 인터랙션을 구현하는 과정까지 전부 직접 처리했다. 코드를 한 줄씩 타이핑하고, 문제가 생기면 로그를 뒤지고 디버거로 한 단계씩 원인을 추적했다. 이제 바이브 코딩과 함께라면 "이 입력 데이터를 차트로 시각화해줘, x축엔 연도를 써줘"라고 말하는 순간 몇 초 안에 차트가 뜨고, "y축을 로그 스케일로 바꿔줘"라는 자연어 지시로 수정도 즉시 이뤄진다.

이 새로운 세상에서 개발자는 세계적인 주방의 헤드 셰프처럼 일한다. 직접 채소를 썰고 스테이크를 굽고 접시를 담을 필요는 없다 — 그건 수셰프나 라인 담당자의 일이다. 대신 음식이 손님에게 나가는 순간 그 결과는 당신의 명성과 미슐랭 별 숫자에 바로 영향을 준다. 손님이 "생선이 과하게 익었다"며 음식을 돌려보내면, 그 책임은 온전히 헤드 셰프의 것이지 수셰프를 탓할 수 없다. AI와 함께 코딩할 때도 원칙은 같다 — 구현을 위임했다는 것이 책임까지 위임했다는 뜻은 아니다. 유저·동료·리더는 어떤 코드를 AI가 작성했는지 신경 쓰지 않는다. 이해관계자에게는 코드의 책임자가 당신이라는 사실만 있을 뿐이다. 새벽 2시에 장애가 났을 때 "그 부분은 AI가 짠 거예요"라는 말은 통하지 않는다 — 결과물은 전적으로 당신의 책임이다.

이 책임의 전환은 해방감과 동시에 무게감을 준다. 구현 세부 사항엔 시간을 덜 쓰고 무엇을 만들고 싶은지에 더 많은 시간을 쏟게 되는 것은 긍정적이다. 직접 코드를 작성하기보다 AI의 제안을 검토하다 보면 비판적으로 코드를 보는 눈이 길러지지만, 손으로 코딩하는 재미를 그리워할 수도 있다. 비인간 어시스턴트에게 요구 사항을 효과적으로 전달하는 데는 높은 학습 장벽이 있지만, 이 과정을 거치며 그 방식을 배우게 된다. 그리고 구현 대부분을 위임하되 최종 결과물의 책임을 끝까지 지다 보면, 자연히 리더처럼 행동하게 된다.

7. 헤드 셰프로서의 더 넓은 책임

전통적인 코딩이 집에서 요리하는 것이라면, 바이브 코딩은 전문 주방을 운영하는 일에 가깝다. 헤드 셰프의 모자를 쓰고 AI 코딩 에이전트를 다루기 시작하면 낯선 변화가 뒤따른다. 10년 넘게 대부분의 개발자는 버전 관리 시스템을 저장·되돌리기·복원 정도의 '저장 버튼'처럼만 써 왔다. 그런데 코딩 에이전트를 쓰기 시작하면서, 과거엔 릴리스 담당 엔지니어나 깃 고수만 다루던 커밋 체리 피킹, 3개 이상 브랜치의 선택적 병합, 복잡한 리베이스 같은 작업을 스스로 하게 된다. 저자들은 이 현상이 바이브 코딩이 한 사람을 '팀'으로 바꾼다는 증거라고 본다 — 최근 쓰게 된 깃 명령어들은 빠르게 움직이는 팀에서 필요한 협업용 명령어였던 것이다.

여러 수셰프로 이뤄진 주방을 떠올리는 것만으로는 부족하다. 어떤 셰프도 섬처럼 홀로 존재하지 않기 때문이다. 바이브 코딩에서 개발자가 맡을 책임은 다음 다섯 가지다 — ① 병렬 작업 관리(여러 AI 에이전트가 몇 분짜리부터 몇 주짜리까지 서로 다른 작업을 동시에 수행하도록 하는 것) ② 복잡한 작업 통합(여러 브랜치의 결과물을 병합하고 충돌을 해결하는 것) ③ 표준 수립(AI 팀이 일관되고 효율적으로 작동하도록 코딩 표준과 절차를 정립하는 것) ④ 온보딩 절차 수립(새로 투입되는 AI 어시스턴트를 위한 워크스페이스·접근 권한·지침을 설정하는 것) ⑤ 대규모 프로젝트 조율(과거엔 겪어 보지 못한 규모의 프로젝트를 프로젝트 매니저처럼 관리하는 것). 이런 팀 규모 운영은 개발자에게 완전히 새로운 영역이고 누구도 AI 에이전트와의 협업에 익숙하지 않지만, 예외 없이 모든 개발자가 헤드 셰프로 승진했다는 것이 저자들의 진단이다. 아무리 뛰어난 개인도 혼자서는 팀을 상대할 수 없듯이, 이 격차는 결국 모두를 AI 에이전트 팀 구축으로 이끌 것이라 본다.

결론. 바이브 코딩 혁명을 받아들이든 거부하든, 이제 모든 소프트웨어 개발 프로젝트에서 사람과 다수의 AI 에이전트가 대화를 나누며 아이디어를 현실로 바꾼다. 더 이상 단순히 코드를 타이핑하는 것이 일이 아니라, 팀이 어떤 결과물을 만들지 정하고 속도를 높여 자주 검증하며 AI 어시스턴트들을 지휘하는 것이 일이 된다. 이 역할을 잘 해내면 바이브 코딩의 풀코스 메뉴, FAAFO를 온전히 즐길 수 있다 — 과거보다 빠르게 배포하고(fast), 더 야심 찬 아이디어를 실험하고(ambitious), 필요할 때 자율적으로 운영하며(autonomous), 코딩의 본래 즐거움을 되찾고(fun), 여러 아이디어를 병렬로 시도하며 언제든 전환할 수 있는 구조를 유지(optionality)하는 것이다. 저자들은 이 모든 것이 우연이 아니라고 강조한다 — 훌륭한 셰프가 주방의 규칙을 직접 세우고 모든 접시를 검수하듯, 개발자도 명확한 표준과 혹독한 검수, 그리고 코드를 덧대기보다 다시 만들 수 있는 용기가 필요하다. 다음 장에서는 지난 70년간 프로그래밍 기술이 크게 발전했음에도 왜 AI가 촉발한 변화가 여전히 근본적인지를 다룬다.

핵심 개념 정리

실무 체크리스트

• [ ] 우리 팀이 하는 바이브 코딩이 "엔지니어가 최소 검토만 하고 AI에 맡기는" 아마추어 방식은 아닌지 점검했는가?
• [ ] AI가 생성한 코드에도 기존과 동일한 보안 검토·테스트 커버리지 기준을 적용하고 있는가?
• [ ] 레거시 코드를 다룰 때 "분석·문서화 → 회귀 테스트 작성 → 수정" 순서를 지키고 있는가?
• [ ] 장애 발생 시 "AI가 짠 코드"라는 이유로 책임을 회피하지 않는 문화가 자리 잡았는가?
• [ ] 여러 AI 에이전트를 병렬로 운용할 때 필요한 브랜치·리베이스·병합 전략을 갖추고 있는가?
• [ ] 새로 투입되는 AI 어시스턴트를 위한 온보딩 절차(워크스페이스·접근 권한·지침)가 문서화돼 있는가?
• [ ] AI 팀이 일관되게 작동하도록 코딩 표준과 절차를 명문화했는가?
• [ ] "뇌를 꺼놓고 작업해도 되는 수준"을 우리 팀 기준으로 명확히 정해 두었는가?
• [ ] FAAFO 다섯 가치 중 우리 조직에 가장 부족한 것이 무엇인지 짚어 봤는가?

연습문제

1. 유형: 구분. "아마추어 바이브 코딩"과 "성숙한 바이브 코딩"의 차이를 이 장의 B2C 인증 기능 예시를 참고해 설명하라.
2. 유형: 판단. 신중론(브렌던 험프리스·제시 영)과 급진론(세르게이 브린)이 겉보기엔 반대 입장 같지만 실제로는 같은 질문을 던지고 있다. 그 질문이 무엇이며, 왜 이것이 두 진영의 공통 근거가 되는지 서술하라.
3. 유형: 사례 분석. 진의 4일간 작업 사례에서 프롬프트·커밋 수치가 뜻하는 바를 "헤드 셰프는 라인 담당자가 아니다"라는 이 장의 주장과 연결해 설명하라.
4. 유형: 적용. 당신의 팀이 바이브 코딩을 도입한다면, §7이 나열한 다섯 가지 책임(병렬 작업 관리·복잡한 작업 통합·표준 수립·온보딩 절차 수립·대규모 프로젝트 조율) 중 가장 먼저 필요한 두 가지를 고르고 이유를 설명하라.

최신 동향 (2026-09 기준)

최신 동향 (검증 2026-09-14) — 이 장이 다루는 '바이브 코딩'의 정의와 두 진영의 논쟁 구도는 그대로 유효하다. 다만 용어 자체는 이 장 이후로도 계속 진화하고 있다.

• 이 장이 직접 인용한 ITRevolution 블로그 글은 여전히 접근 가능하다. 다만 원문(영문)의 실제 수치는 프롬프트 261개·커밋 35개이며, 이 장의 한국어판 인쇄본은 프롬프트 수를 251개로 적고 있다 — §5 본문에서 이 차이를 이미 밝혔다.
• 안드레이 카르파티는 자신이 '바이브 코딩'을 만든 지 1년이 되는 2026년 2월, 이 용어가 원래 "일회성 주말 프로젝트"만을 염두에 둔 것이었다고 밝히며, 전문적인 AI 활용 개발을 가리키는 새 이름으로 '에이전틱 엔지니어링'(agentic engineering)을 제시했다. 이는 이 장이 구분한 '아마추어 바이브 코딩'과 '성숙한 바이브 코딩'의 경계와 같은 문제의식이다. The New Stack 보도
• 이 장이 언급한 보리스 체르니는 2026년 중반 기준으로도 여전히 앤트로픽 클로드 코드의 개발 리더로 활동 중이며, 한 인터뷰에서는 "8개월간 손으로 코드를 작성한 적이 없다"고 밝혀 이 장이 소개한 생산성 향상 흐름이 계속되고 있음을 보여 준다. Fortune 인터뷰

부록 A. 핵심 비교표

부록 B. 추천 참고 자료

외부 자료 (Tier 1 원출처·공식, 생존 확인 2026-09-14)

• 이 장이 직접 인용한 원 출처(진의 사례 전문) — ITRevolution: The Last 80 Hours Of Editing the "Vibe Coding" Book
• 카르파티의 '바이브 코딩 → 에이전틱 엔지니어링' 재정의 보도 — The New Stack
• 클로드 코드 공식 문서 및 제품 페이지 — Claude Code Docs · 제품 소개

본 책 연계 챕터

부록 C. 연습문제 풀이

1. (문제 1 정답) 두 방식의 차이는 "검토를 하느냐 마느냐"가 아니라 "그 검토·구축 과정을 얼마나 빠르게 수행하느냐"에 있다. 이 장이 든 B2C 인증 기능 예시에서, 아마추어 방식이라면 AI가 생성한 인증 코드를 최소한의 검토만 거쳐 그대로 반영하겠지만, 성숙한 바이브 코딩은 여전히 보안 관련 코드를 한 줄 한 줄 검토하고 포괄적인 테스트 스위트를 구축한다 — 다만 그 모든 과정을 이전보다 훨씬 빠르게 수행할 뿐이다.
2. (문제 2 정답) 공통 질문은 "AI를 이용해 소프트웨어를 만들 때 어느 정도까지 뇌를 꺼놓고 작업해도 되는가"다. 신중론은 이 질문에 "거의 안 된다"에 가깝게, 급진론은 "코드 세부 사항은 꺼도 된다"에 가깝게 답할 뿐, 두 진영 모두 이 질문 자체를 논쟁의 축으로 삼고 있다는 점은 같다. 게다가 AI가 개발을 근본적으로 재편하고 있다는 것, 생산성을 높인다는 것, 개발 방식이 AI 발전 속도에 맞춰 함께 진화해야 한다는 것에는 두 진영 모두 이견이 없다.
3. (문제 3 정답) 저자(원출처 기준)는 261개의 프롬프트와 35개의 커밋만으로 4일간 4,176줄의 코드를 완성했다. 중요한 것은 이 수치의 크기 자체가 아니라, 저자가 코드를 한 줄씩 직접 타이핑하지 않고 AI에 구현을 맡기면서도 "결과물이 실제로 정확히 동작하는지"를 검증하는 책임(테스트 스위트를 거의 6배 늘린 것)은 스스로 졌다는 점이다. 이것이 바로 "라인 담당자가 아닌 헤드 셰프"라는 이 장의 주장이 구체적으로 실현된 사례다.
4. (문제 4 정답) 정답은 하나가 아니다. 예를 들어 여러 팀원이 각자 AI 에이전트와 동시에 작업을 시작하는 초기 단계라면 "표준 수립"과 "온보딩 절차 수립"을 가장 먼저 갖춰야 할 것이다. 명확한 코딩 표준과 온보딩 절차가 없으면, 병렬 작업(①)이나 복잡한 작업 통합(②) 단계에서 충돌과 재작업이 커지기 때문이다. 채점 포인트는 "왜 그 두 가지가 다른 세 가지보다 선행돼야 하는지"를 이 장의 논리(표준이 없으면 병렬·통합이 더 어려워진다)로 설명했는가에 있다.